1. Field of the Invention
This invention relates generally to network interface and the tasks performed by the interface to enable the communication between inter-connected computers. More particularly, this invention relates to the interface system and method that the network communications may be more efficiently performed.
2. Description of the Prior Art
Since computer networks and their applications now place ever greater demand for transmitting large volume of data in very high speed among networked data processors/computers, the requirement that two inter-connected data processors must utilize the `communication protocols` to setup appropriate system configurations and procedures in order to carry out the network data exchange. The protocol process may be quite complicated and often become a bottleneck of data transmission. This situation is even more intensified with the emerging multi-media applications wherein more video, audio and other types of data are to be shared and exchanged among the networked data processors for `real time` process and display.
When a plurality of processors are connected as a network to exchange data messages, a set of procedural rules are set forth as the communication protocols. Every networked processing entity must follow this set of procedural rules, i.e., the protocol, which serves as the common language between these processors for communication with each other. In order to properly follow the communication protocol for setting up communication session between two processors in a network, each of the networked processors are often represented as a `finite state` machine. The operational states of these processors are cataloged as a `state table`. Depending on the operation conditions of each of the processors, each processor is identified as being in a specific state.
The communication protocol generally has two modes, i.e., a `connectionless` mode and a `connection-oriented` mode. In a connectionless mode, the sending and receiving processors can communicate by sending and receiving data from each other without requiring that a `connection` be established first. Under that circumstance, each processing entity invokes a finite state machine comprising only two states, i.e., an inactive state and an active state. The transmission of messages among these two processing entities begins when both entities are in active state. Such protocol mode is very simple and can be easily implemented. However, it has several disadvantages because there are no safeguard against erroneous data transmission and no status monitoring and reporting of the communication processes.
On the other hand, if two networked processors attempt to exchange data in a connection-oriented mode, then a `connection` must be established first. When a data processor receives a `connection-oriented` message from another networked processor requesting communication, the message is a protocol message containing a request to the receiving processor that a special sequence of steps are to be executed by the sending and the receiving processors so that the communication can be properly achieved. The finite state machine in such a connection-oriented mode is represented by a more complex state table which comprises more state-event entries. Table 1 shows a specific example of a state table, i.e., the state table of ISO 8073 Class-4 Over CLNS. The states of the processor are listed in Table 1 as a two-dimensional array wherein each processor can be in one of many `states` and in that state the processor may perform different events depending on the protocol definition of the processor. Table 1 is only a state table for one of possible seven layers of a processor and there are state tables like Table 1 for each layer.
FIG. 1 is a flow-chart showing the sequence the steps that a processor carries out in the process of performing a communication with other processors under a `connection-oriented` protocol mode. Once a processor receives a connection-oriented message via a `connection.sub.-- id`, and `request` (step 10) to initiate a communication process, based on the requested connection.sub.-- id contained in the received request, a corresponding finite state machine is activated (step 12). In order to properly process the message received, the event in the state table as requested by the `request` (step 10) must be identified (step 14). The purpose for identifying the event in the state table is to enable the processor to execute a sequence of processing steps according to the rules of communication protocol. Based on the state in the state table as determined by step 12, proper actions are activated (step 16). This sequence of actions are developed and implemented in the finite state machine represented by the state table based on a set of predefined rules according to the communication protocols. After these actions are executed (step 18), the finite state machine may change the state of the FSM (step 20) according the actions as defined by the state table. The process for communication according to the connection-oriented message is completed (step 22) and the protocol entity is ready to receive and process another message including `connection.sub.-- id` and `request` (step 10).
In the process of determining which actions to be executed by the processor in identifying a specific state-event in a state table (step 16), a conventional method most commonly used is by configuring the state table as an two-dimensional array. The first dimension is for identifying an `event` and the second dimension is for identification of a `state` under that `event` in a state table. Each element of that array is associated with a procedure name. The procedure name is used to invoke an executable statement segment which performs a sequence of actions as defined by the state table under that specific `state` and `event`.
This method has several disadvantages. The first disadvantage of this method is that the two-dimensional array requires substantial memory space on a data processor for storage. The memory requirement is increased because size of the state tables expands when the structure and functions of a modern processor and the associated communication protocol become more complicate. In addition to the data storage requirement, extra processing time, search time and access time may also likely to increase as the array is increased in size. This further impedes efficient data communication between processors.
In addition to the aforementioned disadvantages, the table-lookup array method may also be very inefficient because in a state table, there are many `null elements` in the table-lookup array where the `event` under a processor state is an empty set which often occurs when it is impossible for a processor to be in that condition under certain state as defined by the state table. As a matter of fact, as the state table expands when the protocol becomes more complex, more null elements are added to the array. The table-lookup method thus wastes more unnecessary data storage space and search time in storing and processing these null elements in the state tables.
In order to avoid this problem, a nested-select method is used to implement the state table. Each event in a state table corresponds to a procedure name. Each state under a event in the state table is implemented by a separate statement segment. Each statement segment thus define the actions to be carried out under a specific state of a event. These statement segments are embed in a nested-select procedure. The procedure executes a series of `if.sub.-- else` logic steps which sequentially determines a proper state corresponding to the current state of the FSM. Once the specific state is determined, the actions as defined by the appropriate statement segment name corresponding to the event under the selected state are executed.
In order to expeditiously perform the communication between the processors, the states which have higher probability of occurrence should be placed in position within the nested-selected procedure such that the if.sub.-- else tests can be performed on these states as soon as possible. However, the probability of occurrence of the states corresponding to a specific event may not be predicted initially. Under these circumstances, the benefit of priority arrangement may not be realized. Furthermore, if there are many states corresponding to a requested event, the nested-select program may become very large and cumbersome. Especially, under some conditions, same sequence of actions are to be executed for several event-state entries in the state table, the storage space may be wasted by using this conventional nested-select method because more duplicate statement segments are embed in a series of procedures. Meanwhile, unless proper priority arrangement is made, this method may require substantial processing time if the nested select program is expanded to contain a large number of logic steps.
For those skilled in the art, the prior art still present several limitations in the implementation of a finite state machine corresponding to a more complicated state table. Under either the table-lookup array method or the nested-select programming techniques, efficient use of the memory storage space and processing time are not achieved. Therefore, a need still exists in the art of communication among networked processors for an improved technique in implementing a finite state machine for more efficient protocol interface in order to overcome these limitations.